Object management system and method for distributed object system

ABSTRACT

The invention offers a distributed object system that is provided with a load balancing feature and can easily be expanded by adding a new computer to the cluster of server-run computers. By the invention, objects are easily activated and deactivated and easy system service alteration is performed by renewing objects.  
     By request from a client, the object invocation unit  220 - a  or  220 - b  obtains object code and object data from the object access unit  310  in response to remote object invocation, executes the requested method, and requests the object access unit  310  to overwrite the object data. The object manager unit  320  activates or deactivates an object.

BACKGROUND OF THE INVENTION

[0001] Balancing the load of handling remote object invocation in aconventional distributed object system is implemented by evenly objectaccess permissions among client-run computers. For instance, objects areactivated in advance on a plurality of server-run computers and a meansto control the access to the active objects is provided on anyserver-run computer. In response to requests for object access from userprograms on client -run computers, the above means evenly returns objectaccess permissions to the clients. Once having obtained the objectaccess permission, the user programs on client-run computers initiateremote object invocation. A technique of this type is described in, forexample, Japanese Patent Laid-Open Publication No. Hei 10-40118.

[0002] For such system operating in LAN or WAN environments, variationof the traffic for accessing a server from client-run computers isrelatively small and therefore expanding the cluster of server-runcomputers is not often required. Alteration to services provided by thecluster of server-run computers is less required.

[0003] Meanwhile, for such system built by using the Internet, rapidchange of the traffic for accessing servers from client-run computersoccurs. It often happens that the capacity of the cluster of sever-runcomputers becomes insufficient because of rapid increase of the trafficfor accessing a server from the client-run computers after a distributedobject system using the Internet is built. In the event of suchover-traffic condition, the cluster of the server-run computers must beexpanded so as to be capable of handing the traffic for accessing aserver from the client-run computers.

BRIEF SUMMARY OF THE INVENTION

[0004] Previous techniques, however, do not disclose a simple method ofadding a new object, which is to run on server-run computers, toserver-run computers.

[0005] For a distributed object system by using the Internet, servicesprovided by server-run computers change frequently. Consequently, itoften happens that after such system is built, system alternation ismade by renewing objects on server-run computers. Previous techniques,however, do not disclose a simple method of activating or deactivatingobjects distributed on a plurality of server-run computers.

[0006] An object of the present invention is to provide a distributedobject system provided with a load balancing feature, wherein easyaddition and expansion of objects to run on a new server-run computerare possible.

[0007] Another object of the invention is to provide a distributedobject system provided with a load balancing feature, wherein objectscan easily be activated and deactivated and system service alteration ispossible by renewing objects.

[0008] In order to attain the above objects, the invention was devisedto provide a distributed object system with the load balancing featureand make the system work as follows. With an object being not active onthe sever-run computers in advance, on one of the server-run computers,object code and object data are obtained from a managing computer inresponse to a remote object invocation from a client-run computer andthe required method of the object is executed, and moreover the managingcomputer is requested to overwrite the object data. Therefore, when aserver-run computer is added to the cluster of the server-run computersdue to insufficient capacity, it is not necessary to activate objects inadvance on the new server-run machine.

[0009] In order to attain the above objects, in the distributed objectsystem provided with a load balancing feature, objects are activated ordeactivated only on the managing computer without being done on aplurality of serer-run computers. Thus, object exchange can be performedby simple operation; when an object is renewed, it is deactivated on themanaging computer, replaced by a new object, and the new object isactivated there.

[0010] Other and further objects, features and advantages of theinvention will appear more fully from the following description.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] A preferred form of the present invention is illustrated in theaccompanying drawings in which:

[0012]FIG. 1 is an overall system structure diagram showing adistributed object system configured, according to a preferredembodiment of the present invention;

[0013]FIG. 2 is a block diagram showing the configuration of aserver-run computer;

[0014]FIG. 3 is a block diagram showing the configuration of aserver-run computer;

[0015]FIG. 4 is a block diagram showing the configuration of a managingcomputer;

[0016]FIG. 5 shows the structure of an executable-formed object;

[0017]FIG. 6 shows the format of a request message;

[0018]FIG. 7 shows the object code table;

[0019]FIG. 8 shows the object data table;

[0020]FIG. 9 shows the load table;

[0021]FIG. 10 is a flowchart illustrating the object activation processin a first preferred embodiment of the invention;

[0022]FIG. 11 is a flowchart illustrating the object deactivationprocess in the first embodiment;

[0023]FIG. 12 is a flowchart illustrating remote object invocationimplemented in the first embodiment;

[0024]FIG. 13 is a flowchart illustrating object invocation implementedin the first embodiment;

[0025]FIG. 14 is a flowchart illustrating object invocation implementedin the first embodiment, a continuation of FIG. 13;

[0026]FIG. 15 is a flowchart illustrating the object obtaining processin the first embodiment;

[0027]FIG. 16 is a flowchart illustrating the object overwrite processin the first embodiment;

[0028]FIG. 17 shows the structure of an executable-formed object for usein a second preferred embodiment of the invention;

[0029]FIG. 18 is a flowchart illustrating object invocation implementedin the second embodiment; and

[0030]FIG. 19 is a flowchart illustrating the object overwrite processin the second embodiment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0031] A first preferred embodiment of the present invention will bedescribed in detail below with reference to the drawings.

[0032]FIG. 1 shows a distributed object system configured, according toa preferred embodiment of the present invention. This distributed objectsystem model embodiment comprises computers 100, 200-a, 200-b, and 300interconnected across a network 10.

[0033] The computer 100 is a client-run computer that comprises a userprogram 110 and a remote object invocation unit 120. The user program110 initiates remote invocation of an object on a server-run computerwith a method whose name is specified by the user. The remote objectinvocation unit 120 generates a request message 700, which is presentedin FIG. 6, for remote object invocation with the message contents beingsupplied from the user program 110, sends the request message to a loadbalancing unit 210-a or 210-b on a server-run computer, and receives theresult of method execution in accordance with the request message 700.The user program 110 is a remote object invocation executing programthat allows the user to specify data such as a method name and argumentsto be passed to the method.

[0034] In a system, for instance, comprising client programs that useobjects on server-run computers from a remote place and objects managedunder servers that are remotely accessed from a program on a client-runserver, a client program is equivalent to the user program 110. In adistributed object system, for instance, comprising HTML-format filescontaining hypertexts with links for remote object invocation, WWWbrowsers, on the window of which HTML-format file contents aredisplayed, WWW servers that accepts a request from a WWW browser andreturns an HTML-format file to the browser, and objects to run asprograms that are executed via a WWW server upon the selection of a linkin an HTML-format file hypertext, an HTML-format file invoked on the WWWbrowser window is equivalent to the user program 110.

[0035] The computer 200-a is a server-run computer that invokes aspecific object in response to a request for remote object invocationfrom the client-run computer 100 and executes the requested method ofthe object.

[0036] The load balancing unit 210-a receives a request message 700 andselects a server-run computer that performs the task of objectinvocation and method execution, based on load information. If the thusselected server-run computer is the local server-run computer 200-a, theload balancing unit transfers the request message 700 to its localobject invocation unit 220-a. If the selected server-run computer isanother server-run computer 200-b, the load balancing unit transfers therequest message 700 to the object invocation unit 220-b of anotherserver-run computer 200-b.

[0037] Upon receiving the request message from the load balancing unit210-a on its local server-run computer 200-a or the load balancing unit210-b of another server-run computer 200-b, the object invocation unit220-a derives an object code identifier 710, an object data identifier720, and a method name 730 from the request message 700, which ispresented in FIG. 6, to identify the object to be invoked and the methodto be executed, and transfers them to an object access unit on themanaging computer 300. Following that, the object invocation unit 220-aon the local server-run computer 200-a receives object code and objectdata from the object access unit 310 and executes the requested method.

[0038] Furthermore, the object invocation unit 220-a on the localserver-run computer 200-a transfers the object data fixed after themethod execution to the object access unit on the managing computer 300.Then, the result of the method execution is transferred to the remoteobject invocation unit 120 on the client-run computer 100.

[0039] The present invention embodiment was devised to make thedistributed object system work as follows. With an object being notactive on the sever-run computer 200-a or 200-b in advance, in responseto a remote object invocation from the remote object invocation unit 120on the client-run computer 100, the sever-run computer 200-a or 200-bobtains object code and object data from the managing computer 300 andexecutes the requested method of the object, and moreover requests themanaging computer 300 to overwrite the object data. Therefore, when aserver-run computer is added to the distributed object system because ofinsufficient capacity of the sever-run computer 200-a or 200-b, it isnot necessary to activate objects in advance and easy system expansionis possible. (Specifically, triggered by a service request from theclient-run computer 100, the managing computer 300 downloads the objectcode and object data of the object required for the service to one ofthe server-run computer 200-a, 200-b, and soon and issues the command toactivate the downloaded object. Thus, the object need not be activebeforehand on any of the server-run computer 200-a, 200-b, and so on.)

[0040] The computer 300 is the managing computer that performs objectcode and object data management. The object access unit 310 on themanaging computer 300 receives an object code identifier 710, an objectdata identifier 720, and a method name 730 contained in the requestmessage 700 from the object invocation unit 220-a on the sever-runcomputer 200-a, obtains the identified object data and object code froman object data table 340 and an object code table 350 respectively, andtransfers them to the object invocation unit 220-a on the sever-runcomputer 200-a. Moreover, when the object access unit 310 on themanaging computer 300 receives processed object data with the objectdata identifier 720 and the method name 730 specified in the requestmessage 700 from the object invocation unit 220-a on the sever-runcomputer 200-a, it writes the processed object data over thecorresponding data in the object data table 340.

[0041] An object manager unit 320 on the managing computer 300, whenrequested to activate an object from a user program for objectmanagement 330, registers its object code into the object code table 350and its object data into the object data table 340 and activates theobject.

[0042] Moreover, the object manager unit 320, when requested todeactivate an object from the user program for object management 330,deletes its object code from the object code table 350 and its objectdata from the object data table 340 and deactivates the object.

[0043] The user program for object management 330 on the managingcomputer 300 is a program that allows the user to issue a request toactivate or deactivate an object. In a distributed object system, forinstance, designed such that a command to active an object and a commandto deactivate an object with the object code identifier 710 and theobject data identifier 720 specified as arguments are used to implementobject activation and deactivation, these commands are equivalent to theuser program for object management 330. In a system, for instance,designed such that an object manager tool is used to implement objectactivation and deactivation, the object manager tool is equivalent tothe user program for object management 330.

[0044] The object code table 340 contains a list of the object codes ofactive objects.

[0045] The object code table 350 contains a list of the object codes ofactive objects.

[0046] Executable-formed objects 360 are objects that can be activatedon the distributed object system as executable programs represented inaccordance with the format of an executable formed object 500 as will bepresented in FIG. 5. The executable-formed objects 360 are generated inadvance by a translation program such as a compiler from source programsdescribed in an object-oriented programming language or a programminglanguage that enables object description. Before the start of objectoperation, these objects are installed into the managing computer 300via a storage device such as files.

[0047] In the present invention embodiment, a plurality of server-runcomputers 200-a and 200-b do not perform object activation anddeactivation, but only the managing computer 300 does so. Thus, easysystem alternation is possible; when an object is renewed, it isdeactivated on the managing computer 300, and then it is replaced by anew object and the new object is activated there.

[0048] The server-run computer 200-b comprises the componentscorresponding to those of the server-run computer 200-a; each component(e.g., 210-b) of the former is identical to the corresponding component(e.g., 210-a) of the latter. This means that multiple server-runcomputers can be arranged in a cluster, though the present inventionincludes two server-run computers 200-a and 200-b arranged on the serverside.

[0049] The present invention embodiment allows the components of theclient-run computer 100 to be also put available on the server-runcomputer 200-a or 200-b. This means that an object invoked on theclient-run computer 100 can be used as the user program 110 to invokeanother object.

[0050]FIG. 2 shows in detail how the client-run computer 100 isconfigured with entities as constituents of the present embodiment ofthe invention.

[0051] The remote object invocation unit 120 consists of a requestmessage generator 121 and a send/receive port 122. The request messagegenerator 121 generates a request message 700 for remote objectinvocation with a method name specified, supplied from the user program110. The send/receive port 122 sends the request message 700 to theserver-run computer 200-a or 200-b and receives the result of methodexecution from the object invocation unit 220-a or 220-b on theserver-run computer 200-a or 200-b.

[0052]FIG. 3 shows in detail how the server-run computer 200-a isconfigured with entities as constituents of the present embodiment ofthe invention.

[0053] The load balancing unit 210-a consists of a receive port 211-a, aserver-machine selector 212-a, a load manager 213-a, and a load table214-a.

[0054] The receive port 211-a receives a request message 700 for remoteobject invocation. The server-machine selector 212-a receives therequest message 700 from the receive port 211-a and selects a server-runcomputer that performs the task of execution of the requested method ofthe object , based on load information that is under the management ofthe load manager 213-a. If the server-machine selector 212-a selects itslocal server-run computer 200-a, then, it transfers the request message700 to the object invocation unit 220-a on the local server-run computer200-a. If the server-machine selector 212-a selects another server-runcomputer 200-b, then, it transfers the request message 700 to the objectinvocation unit 220-b on another server-run computer 200-b.

[0055] The load manager 213-a sends the load information on its localserver-run computer 200-a to the load manager on another server-runcomputer. The load manager 213-a also receives load information onanother server-run computer 200-b from the load manager thereon andsaves this information in the load table 214-a.

[0056] The load table 214-a is a table wherein the load information onthe server-run computer 200-a and other server-machines is stored.

[0057] The object invocation unit 220-a consists of a request messageinterpreter 221-a, an object controller 222-a, an object processor223-a, and a response sender 224-a.

[0058] The request message interpreter 221-a receives the requestmessage from the load balancing unit 210-a on its local server-runcomputer 200-a or the load balancing unit 210-b on another server-runcomputer 200-b, derives an object code identifier 710, an object dataidentifier 720, a method name 730, and user data 750 from the requestmessage 700, and transfers them to the object controller 222-a. Theobject controller 222-a transfers the object code identifier 710, theobjet data identifier 720, and the method name 730 to the object accessunit 310 on the managing computer 300 and obtains object code and objectdata. After the object processor 223-a executes the method of theobject, the object controller 222-a also transfers the object dataidentifier 720, the object data fixed after the method execution, andthe method name 730 to the object access unit 310 on the managingcomputer 300.

[0059] The object processor 223-a receives the object code, object data,method name, and user data from the object controller 222-a and executesthe method of the object. Moreover, the object processor 223-a returnsthe object data fixed after the method execution to the objectcontroller 222-a.

[0060] The response sender 224-a receives the result of method executionfrom the object processor 223-a and transfers it to the remote objectinvocation unit 120 on the client-run computer 100.

[0061]FIG. 4 shows in detail how the managing computer 300 is configuredwith entities as constituents of the present embodiment of theinvention.

[0062] The object access unit 310 consists of an object obtainingsection 311, a data obtaining section 312, a code obtaining section 313,an object writing section 314, and a data writing section 315. Theobject obtaining section 311 receives the object code identifier 710,object data identifier 720, and method name 730 from the objectinvocation unit 220-a on the server-run computer 200-a. The codeobtaining section 313 obtains the identified object code from the objectcode table 350. The data obtaining section 312 obtains the identifiedobject data from the object data table 340. Then, the object obtainingsection 311 transfers the object code and the object data to the objectinvocation unit 220-a on the server-run computer 200-a.

[0063] The object writing section 314 receives the object dataidentifier, the object data fixed after the method execution, and themethod name from the object invocation unit 220-a on the server-runcomputer 200-a. The data writing section 315 saves the object data fixedafter the method execution in the object data table 340.

[0064] The object manager unit 320 consists of a code registeringsection 321, a data registering section 322, a code deleting section323, and data deleting section 324. After the retrieval of a specificobject from the database of executable-formed objects 360, the coderegistering section 321 registers its object code into the object codetable 350. The data registering section 322 registers its object datainto the object data table 340. The code deleting section 323 deletesits object code from the object code table 350. The data deletingsection 324 deletes its object data from the object data table 340.

[0065]FIG. 5 shows the data structure of the executable-formed objectsin the present embodiment of the invention.

[0066] An executable-formed object 360 (its data structure is denoted byreference number 500) is composed of control information 510, objectcode 520, and object data 530. The control information 510 part includesan object code identifier 511 to identify the object code itself. Thisobject code identifier 511 indicates the type of the object; objectswith a same object code identifier are those of the same type, havingthe same object code. Object code 520 is aggregation of the programcodes of all methods that the object has. An object is capable of havinga plurality of methods. Executing a method is executing the program codeof the method that reads and/or writes object data 530.

[0067] Attribute A per method 522 in the object code 520 part isinformation that indicates whether the method is synchronized ornon-synchronized for each method. Here, the synchronized method meansthat, while the synchronized method of the object is executed, othersynchronized methods of the object including the synchronized methodbeing executed cannot be executed. The non-synchronized method meansthat, while the non-synchronized method of the object is executed, othersynchronized and non-synchronized methods of the object including thenon-synchronized method being executed can be executed. Code per method523 is the program code of each method.

[0068] Object data 530 is aggregation of all members data that theobject has. The section of data per object member 532 contains the datafor each member. An object is capable of having a plurality of members.During method execution, the object data 530 is read and overwritten bythe code per method 523.

[0069]FIG. 6 shows the format of the request message 700 that is sentfrom the client-run computer 100 to the server-run computer 200-a or200-b, just after the user program initiates a remote object invocation.

[0070] The request message 700 is composed of four fields. The objectcode identifier 710 indicates the type of the object to be invoked onthe server-run computer 200-a or 200-b. The object data identifier 720is used to identify the object to be invoked on the server-run computer200-a or 200-b. The method name 730 indicates the name of the method tobe executed on the server-run computer 200-a or 200-b. The user data 750is the data such as user-specified arguments to the method and this dataspecified within the user program is passed to the object when therequested method of the object is executed.

[0071]FIG. 7 shows the table 350 for object code management, maintainedin the managing computer 300.

[0072] The object code table 350 (its data structure is denoted byreference number 800) maps an object code identifier 810 to an objectcode 840. Number of objects 820 indicates the number of active objectshaving the same object code. Status 830 indicates whether the objectcode is available now. If the status 830 is “ON,” the object code isavailable. If the status 830 is “OFF,” the object code is unavailable.The object code table 800 is a list of the object codes of activeobjects, or in other words, a list of the object types that can beinvoked on the server-run computer 200-a or 200-b.

[0073]FIG. 8 shows the table 340 for object data management, maintainedin the managing computer 300.

[0074] The object data table 340 (its data structure is denoted byreference number 900) maps an object data identifier 910 to object data940. The object data identifier 910 identifies an object havingparticular object data. The object code identifier 920 indicates theobject code coupled with the object data. The object use flag 930indicates whether the object is used now. The “In-Use” object use flagindicates that the object is invoked and read. The “Unused” object useflag indicates that the object is not invoked for read. The object datatable 900 is a list of active objects, or in other words, a list of theobjects that can be invoked on the server-run computer 200-a or 200-b.

[0075] As the client-run computer 100 executes a remote objectinvocation by issuing a request message 700 in which a method name 730is specified, the requirement for the server-run computer 200-a or 200-bto execute the method by invoking the object is that the object isactive on the managing server 300. When the object is active on themanaging computer 300, it is identified by the object data identifier910 with its object data 940, its object code identifier 920 (or 810),and the associated object code 840. Same objects may exist that are ofsame type and assigned a same object data identifier 910. (Same-typeobjects are those assigned a same code identifier and of same datastructure.)

[0076] If a plurality of requests for remote invocation of a same objectfor which the execution of a synchronized method is requested aresimultaneously issued from the client-run computers 100, the method isnot executed at the same time, but it is sequentially executed(serialized) to meet the invocation requests. Serialized methodexecution should apply to a method that overwrites the data per member;it can keep the data per member consistent.

[0077] If a plurality of requests for remote invocation of a same objectfor which the execution of a non-synchronized method is requested aresimultaneously issued from the client-run computers 100, the methodexecution takes place concurrently, not in the serialized manner.Concurrent method execution should apply to a method that simply readsthe data per member; it can increase the efficiency of execution.

[0078]FIG. 9 shows the table for load information management, maintainedin the server-run computer 200-a or 200-b. The load table 600 (or 214-a)maps a server-machine identifier 610 to load information 620. Theserver-machine identifier 610 is a unique identifier assigned to theserver-run computer 200-a or 200-b. The load information 620 is loadinformation for the identified server-run computer. The contents of loadinformation are not definitely specified herein, but generally, a CPUutilization factor and a request message arrival factor that can beacquired easily may be used as this information.

[0079] Then, the object activation process flow in the present inventionembodiment will be explained blow with reference to FIG. 10.

[0080] When activating objects, activate the user program for objectmanagement 330 on the managing computer 300 and specify anexecutable-formed object 500 as the object to be activated and thenumber of objects as the input to the program. The user program forobject management issues an object activation request with the aboveparameters to the code registering section 321 of the object managerunit 320 (1001). The code registering section 321 extracts the objectcode identifier 511 and object code 520 from the executable-formedobject 500 and registers them into the object code table 800. The coderegistering section 321 also sets the number of objects 820 in theobject code table 800 at the number of objects passed from the userprogram for object management and sets the status 830 “OFF” (1002). Thedata registering section 322 generates as many object data identifiers910 as the number of objects (1003). The data registering section 322extracts the object data 530 from the executable-formed object 500 andregisters a triple of entries, object data identifier 910, object data940, and object code identifier 810 into the object data table. At thesame time, the object use flag is set “Unused” (1004). The coderegistering section 321 changes the status 830 of the object codeidentifier 810 to “ON” (1005).

[0081] At the managing computer 300, in this way, the user program forobject management 330 can issue the object activation request with thenumber of objects 820 specified per object code identifier 810.Specifically, select an executable-formed object 500 that is an objectrepresented as an executable program and specify the number of objects820 and input them to the user program for object management 330, andthe program commands the managing computer to activate the object. Theprogram issues the object activation request with the user-inputparameters to the object manager unit 320 on the managing computer 300.The object manager unit 320 activates the object consisting of theobject code 520 and the object data 530 contained in the specifiedexecutable-formed object 500. Specifically, the object manager unit 320reads the object code 520 and the object data 530 from the specifiedexecutable-formed object 500 and registers them into the object codetable 800 and the object data table 900, respectively. The object code520 and the object data 530 contained in the executable-formed object500 exist in the object code table 800 and the object data table 900respectively and this state, once set, is that the object is active. Ifthere exists an active object or objects with the same object codeidentifier as the object code identifier 511 of the specifiedexecutable-formed object 500 when the user program for object management330 issues the object activation request to the object manager unit 320,the object manager unit 320 additionally activates same-type objects sothat as many objects as the specified number of objects 820 will beactive.

[0082] Next, the object deactivation process flow in the presentinvention embodiment will be explained blow with reference to FIG. 11.

[0083] When deactivating objects, activate the user program for objectmanagement 330 on the managing computer 300 and specify the object codeidentifier 810 of an object that you want to deactivate as the input tothe program. The program for object management 330 issues an objectdeactivation request with the above parameter to the code deletingsection 323 of the object manager unit 320 (2001). The code deletingsection 323 changes the status 830 of the object identified by thespecified object code identifier in the object code table to “OFF”(2002). The data deleting section 324 deletes all object data inconnection with the specified object code identifier from the objectdata table 900 (2006). The code deleting section 323 deletes thespecified object code from the object code table 800 (2007).

[0084] At the managing computer 300, in this way, the user program forobject management 330 can issue the object deactivation request perobject code identifier 810. Specifically, specify the object codeidentifier 810 of an object that you want to deactivate and input it tothe user program for object management 330, and the program commands themanaging computer to deactivate the object. The program issues theobject deactivation request with the user-input parameter to the objectmanager unit 320. The object manager unit 320 deactivates the objectwith the specified object code identifier 810. Specifically, the objectmanager unit 320 deletes the object code 840 identical to the specifiedobject code identifier 810 from the object code table 800 and the objectdata 940 in connection with the object code from the object data table900. The object code 520 and the object data 530 contained in theexecutable-formed object 500 are thus deleted from the object code table800 and the object data table 900 respectively and this state, once set,is that the object is inactive. If both an object code identifier 810and an object data identifier 910 are specified when the user programfor object management 330 issues the object deactivation request to theobject manager unit 320, the object manager unit 320 deactivates onlythe object with the object data identifier 910.

[0085] Then, the remote object invocation process flow on the client-runcomputer 100 in the present invention embodiment will be explained blowwith reference to FIG. 12.

[0086] First, activate the user program 110 on the client-run computer100 and specify the object code identifier and object data identifier ofan object to invoke, the name of a method to execute, and user data (maybe blank) as the input to the program. The user program 110 requests therequest message generator 121 of the remote object invocation unit 120to generate a request message for remote object invocation with theabove parameters (3001). How to obtain the object code identifier,object data identifier, and method name is not definitely specifiedherein. The simplest method of obtaining the object data identifier isto retrieve it from the object data table 900. The request messagegenerator 121 generates a request message 700 with the object codeidentifier, object data identifier, method name, and user dataparameters passed from the user program 110 and transfers the message tothe send/receive port 122 (3002). The send/receive port 122 sends therequest message 700 to the receive port 211-a of the server-run computer200-a or the receive port of the server-run computer 200-b. How todetermine what receive port to which the message is sent is notdefinitely specified herein. The simplest port selection method is touse a naming service of a Domain Name Service (DNS). Another possiblemethod is invoking a program for management of receiving-end ports(destinations) that allocates a destination port and supplies it to theclient program on the client-run computer 100.

[0087] The send/receive port 122 of the remote object invocation unit120 on the client-run computer 100 receives the result of methodexecution from the response sender 224-a on the server-run computer200-a or the response sender on the server-run computer 200-b (3004).The user program 110 receives the result of method execution from thesend/receive port (3005). At the client-run computer 100, in this way,the user program 110 can request a remote object invocation with themethod name specified of the remote object invocation unit 120. Theremote object invocation unit 120 generates a request message 700 forthe remote object invocation and sends it to the load balancing unit210-a or 210-b on the server-run computer 200-a or 200-b, and thereafterreceives the result of the method execution.

[0088] Now, the object invocation (method execution) process flow on theserver-run computer 200-a in the present invention embodiment will beexplained with reference to FIGS. 13 and 14.

[0089] The receive port 211-a of the load balancing unit 210-a on theserver-run computer 200-a receives the request message 700 and transfersit to the server-machine selector 212-a (4001). The server-machineselector 212-a obtains load information from the load manager 213-a, andbased on this information, selects a server-run computer to perform thetask of object invocation and method execution in response to therequest message 700 just received (4002).

[0090] A method in which the server-machine selector 212-a of the loadbalancing unit 210-a selects a server-run computer, based on the loadinformation is not definitely specified herein. If the load informationis, for example, a CPU utilization factor, selecting a server-runcomputer is generally based on round robin scheduling; whereas, such amethod may be used that, if the CPU utilization factor of a server-runcomputer reaches a specific value, another server-run computer with alower CPU utilization factor is a priority of selection. A method inwhich the load manager 213-a manages load information is not definitelyspecified herein. If the load information is, for example, a CPUutilization factor, the following method is possible. The load manager213-a or 213-b periodically measures the CPU utilization factor of itslocal server-run computer and retains it. The load manager 213-aperiodically receives from another server-run computer 200-b the CPUutilization factor information obtained there and reflects thisinformation in the load table 214-a.

[0091] In the next step (4003), judgment is made as to whether theselected machine is its local sever-run computer. If the localserver-run computer 200-a is selected, the server-machine selector 212-atransfers the request message 700 to the request message interpreter221-a of the object invocation unit 220-a (4004). If another server-runmachine 200-b is selected, the selector 212-a transfers the requestmessage 700 to the corresponding request message interpreter on theserver-run computer 200-b (4005). The request message interpreter 221-areceives the request message 700 from the server-machine selector 212-aon its local server-run machine 200-a or the correspondingserver-machine selector on another server-run computer 200-b. From therequest message 700, the interpreter derives the object code identifier710, object data identifier 720, method name 730, and user data 750 andtransfers them to the object controller 222-a (4006).

[0092] The object controller 222-a on the server-run computer 200-atransfers the object code identifier 710, object data identifier 720,and method name 730 to the object obtaining section 311 on the managingcomputer 300 (4007). The object controller 222-a receives object code840 and object data 940 from the object obtaining section 311 andtransfers them together with the information derived from the requestmessage 700 to the object processor 223-a (4008).

[0093] The object processor 223-a on the server-run computer 200-aexecutes the requested method by using the object code 840 and theobject data 940 passed from the object controller (4009). The objectcontroller 222-a receives the object data fixed after the methodexecution from the object processor 223-a. Then, the controllertransfers the object data identifier, the object data fixed after themethod execution (object invocation), and the method name to the objectwriting section 314 on the managing computer 300 (4010).

[0094] The response sender 224-a on the server-run computer 200-areceives the result of the method execution from the object processor223-a and sends it to the send/receive port 122 on the client-runcomputer 100 (4011).

[0095] As described of the above steps 4001 through 4011, the server-runcomputer 200-a operates as follows. The load balancing unit 210-areceives the request message 700 and performs load balancing. From theobject access unit 310 on the managing computer 300, the objectinvocation unit 220-a obtains the object data 530 and object code 520 ofthe object identified by the object code identifier 710 and object dataidentifier 720 in the request message 700. The object invocation unit220-a executes the specified method in the object code 520 part by usingthe object data 530. Specifically, the method in the object code 520part computes while reading the members in the object data 530 part orwriting data to them. Because the method in the object code 520 part maywrite object data 530, the object access unit 310 is requested tooverwrite the object data 530.

[0096] The object obtaining process flow on the managing computer 300 inthe present invention embodiment will be explained below with referenceto FIG. 15.

[0097] The object obtaining section 311 on the managing computer 300receives the object code identifier 710, object data identifier 720, andmethod name 730 from the object controller 222-a on the server-runcomputer 200-a (5001). The code obtaining section 312 obtains the objectcode 840 identified by the object code identifier 710 and its status 830from the object code table 800 (5002). Judgment is made to whether theobject code 840 has been obtained successfully and its status 830 is“ON” (5003). If this is judged untrue, it is an error indicating thatthe object is not active (5004). The data obtaining section 313 obtainsthe object data 940 identified by the object data identifier 910 and itsobject use flag 930 from the object data table 900. Judgment is made asto whether the object data has been obtained successfully (5006). Ifthis is judged untrue, it is an error indicating the object is notactive (5004). The data obtaining section 313 judges whether theattribute A 522 of the specified method is “Synchronized” (5007).

[0098] If the attribute A 522 is “Synchronized,” further judgment ismade as to whether the object use flag 930 of the object data identifier910 is “Unused” (5008). If the flag 930 is “In-Use,” the data obtainingsection 313 enters the wait state, waiting until the flag has changed to“Unused” (5009). If the flag 930 is “Unused,” the data obtaining section313 changes the flag 830 to “In-Use” (5010). The object obtainingsection 311 transfers the obtained object code and data to the objectcontroller 222-a on the server-run computer 200-a (5011). The objectobtaining section does so even if the attribute A 522 of the method is“Non-synchronized” (5011).

[0099] At the managing computer 300, In this way, the object access unit310 receives the request to obtain the object data 940 and object code840 from the object invocation unit 220-a on the server-run computer200-a, obtains them from the object code table 800 and the object datatable 900, and transfers them to the object invocation unit 220-a. If,however, the above request is intended for synchronized methodexecution, the object access unit 310 serializes the object dataobtained from the object data table 900. As a result, if a plurality ofremote object invocation requests for a synchronized method of a sameobject are issued from the client-run computers 100, the server-runcomputer 200-a or 200-b performs object invocation (method execution) ina serialized manner.

[0100] The object overwrite process flow on the managing computer 300 inthe present invention embodiment will be explained below with referenceto FIG. 16.

[0101] The object writing section 314 receives the object dataidentifier 910, the object data 940 fixed after method execution, andthe method name 730 (6001). The data writing section 315 writes theobject data fixed after method execution over the object data 940identified by the object data identifier 910 in the object data table900 (6002). The object writing section 315 changes the object use flag930 of the object data identifier 910 to “Unused” (6003). At themanaging computer 300, in this way, the object access unit 310 receivesthe request to overwrite the object data 940 with the object data fixedafter method execution from the object invocation unit 220-a andoverwrites the specified data in the object data table 900.

[0102] Next, a second preferred embodiment of the invention will bedescribed in detail, based on the drawings. FIGS. 1, 2, 3, and 4 alsoapply to the distributed object system model as the second embodiment ofthe invention to illustrate its overall and detailed configurations.FIGS. 6, 7, 8, and 9 also apply to the second embodiment to illustratethe data structure thereof. However, the structure of theexecutable-formed object 500 for the first embodiment is modified.

[0103]FIG. 17 shows the data structure of an executable-formed object inthe second embodiment of the invention. Here, attribute B per method 524is added to the executable-formed object 500 shown in FIG. 5. A “Read”attribute B 524 means that the object data does not change during themethod execution. A “Write” attribute B 524 means that the object datais rewritten during the method execution.

[0104] Activating and deactivating objects and the action on theclient-run computer 100 in the second embodiment are the same as thosein the first embodiment.

[0105] The flow of action on the server-run computer 200-a in the secondembodiment also follows the steps illustrated in FIG. 13 for the firstembodiment before the step 4008. The subsequent flow of action on theserver-run computer 200-a in the second embodiment will be explainedbelow with reference to FIG. 18.

[0106] The object controller 222-a on the server-run computer 200-areceives the object code 520 and object data 530 from the objectobtaining section 311 and transfers them together with the informationderived from the request message 700 to the object processor 223-a(7008). The object processor 223-a executes the requested method byusing the received object code 520 and object data 530 (7009). Theobject controller 222-a receives the object data fixed after the methodexecution. Then, the object controller derives the attribute A 522 andattribute B 524 of the method name from the object code 520 and firstjudges whether the attribute B 524 is “Read” (7010). If the attribute B524 is “Write,” the object controller transfers the object dataidentifier 910, the object data 940 fixed after the method execution,and the method name 730 to the object writing section 314 on themanaging computer 300 (7011). If the attribute B 524 is “Read,” theobject controller then checks that the attribute A 522 is not“Synchronized” (7012). If the attribute A is “Synchronized,” the objectcontroller transfers the object data identifier, null object data, andmethod name to the object writing section 314 (7013). The responsesender 224-a on the server-run computer 200-a receives the result of themethod execution from the object processor 223-a and sends it to thesend/receive port 122 on the client-run computer 100 (7014).

[0107] The object obtaining process flow on the managing computer 300 inthe second embodiment is the same as that in the first embodiment.

[0108] The object overwrite process flow on the managing computer 300 inthe second embodiment will be explained below with reference to FIG. 19.

[0109] The object writing section 314 on the managing computer 300receives the object data identifier 910, object data 940, and methodname 730 (8001). The data writing section 315 judges whether theattribute B 524 of the method name is “Write” (8002). If the attribute B524 is “Write,” the data writing section 315 overwrites the object data940 identified by the object data identifier 910 with the object datafixed after the method execution in the object data table 900 (8003).The data writing section 315 changes the object use flag 930 of theobject data identifier 910 to “Unused” (8004). This data writing section315 does so even if the attribute B 524 is “Read” (8004).

[0110] In the second embodiment, if a method of Read and Synchronizedattributes is executed on the sever-run computer 200-a, because thespecified method in the object code part does not overwrite the membersin the object data part, the object access unit 310 is not requested tooverwrite the object data, but is requested to simply return the objectuse flag to “Unused” from “In-Use” that has been set when obtaining theobject data. If a method of Read and Non-synchronized attributes isexecuted on the server-run computer 200-a, similarly, because thespecified method in the object code part does not overwrite the membersin the object data part, the object access unit 310 is not requested tooverwrite the object data. In this case, the object use flag of theobject data is not used, and therefore the object access unit is notrequested to change the object use flag 930. As a result, by classifyingmethods into “Read” and “Write” by using the attribute B 524 per method,the cost of communication between the server-run computer 200-a and themanaging computer 300 can be reduced.

[0111] System expansion to cope with rapid traffic increase in the firstand second embodiments will be explained below.

[0112] If rapid increase of the access from the client-run computers 100to the sever-run computer 200-a or 200-b occurs beyond the processingcapacity of the server-run computers 200-a and 200-b, a new server-runcomputer must be added to the system. In this case, system expansion ispossible by connecting a new server-run computer equipped with the loadbalancing unit and the object invocation unit to the network 10 andaltering the system operation such that some of the request messagesreceived at the load balancing unit 210-a or 220-b may be forwarded tothe load balancing unit of the new server-run computer or some of therequest messages received at the load balancing unit of the newserver-run computer may be forwarded to the load balancing unit 210-a or220-b. For conventional distributed object systems, it is necessary toinstall objects and activate them on a new server-run computer connectedto the server cluster. By contrast, the work of installing andactivating objects on the new server-run computer is not necessary inthe similar system offered by the present invention. This is becauseobjects are activated only on the managing computer 300 and when the newserver-run computer receives a request for remote object invocation fromthe client-run computer 100, its object invocation unit obtains objectcode and objet data of the specified object from the object access unit310 on the managing computer 300 and executes the requested method.

[0113] Furthermore, system service alteration to meet a service changerequest in the first and second embodiments will be explained below.

[0114] If the system in question is requested to alter its service,e.g., altering the service provided by an object by altering the methodspecification, it is necessary to replace the active object by a newobject made to the altered specification. Such service alteration ispossible by deactivating the object on the managing computer 300,replacing the object by a new object as the executable-formed object 360made to the altered specification, and activating the new object.Conventional distributed object systems, comprising a plurality ofserver-run computers and clients, must cope with such service alterationas follows. The object to change is deactivated on each server-runcomputer, replaced by a new object as the executable-formed object madeto the altered specification, and the new object is activated on eachserver-run computer. By contrast, the distributed object system offeredby the present invention does not require a series of operations:deactivating the object to change on the server-run computers 200-a and200-b; replacing it by a new object as the executable-formed object madeto the altered specification; and activating the new object on theserver-run computers 200-a and 200 b. This is also because objects arealways activated/deactivated on the managing computer 300 and whenreceiving a request for remote object invocation from the client-runcomputer 100, the object invocation unit 220-a or 220-b obtains objectcode and object data of the specified object from the object access unit310 on the managing computer 300 and executes the requested method.

[0115] Then, an application example of the present invention will beexplained below.

[0116] Now, a shopping system using WWW and distributed objects will beexplained as an example of application with reference to theconfiguration drawing of the distributed object system model shown inFIG. 1.

[0117] The client-run computer 100 in this application example comprisesa WWW browser and HTML-format files. The WWW browser corresponds to theremote object invocation unit 120 and the HTML-format files correspondto the user program 110. It is assumed that a specific object codeidentifier, object data identifier, method name, and arguments to methodare embedded in each of the links in HTML-format file hypertexts. Byselecting a link in the hypertext of an HTML-format file displayed onthe WWW browser window, the user requests the system to return anotherHTML-format file as the result of accessing the system. This correspondsto the process that the user program 110 requests the remote objectinvocation unit 120 to issue a remote object invocation request with amethod name specified to the server side and return the received resultof the method execution.

[0118] The server-run computer 200-a or 200-b in the present applicationexample comprises a WWW server and an object invocation unit 220-a or220-b. In the application example, in addition, a router with a loadbalancing feature, which is not shown, is assumed placed between theclient-run computer 100 and the server-run computer 200-a or 200-b. Thisrouter with a load balancing feature receives a request message 700 forreturning an HTML-format file which contains result of method executionfrom the WW browser and forwards the request message 700 to theserver-run computer 200-a or 200-b, according to the round robinscheduling or load condition. The combination of the WWW server and therouter with a load balancing feature corresponds to the load balancingunit 210-a or 210-b. How the WWW server receives the request message andtransfers it to the object invocation unit 220-a or 220-b is notdefinitely specified herein. A typical interface example between the WWWserver and an external program is a Common Gateway Interface (CGI).

[0119] The managing computer 300 in the present application examplecomprises the object access unit 310, object manager unit 320, userprogram for object management 330, object data table 340, object codetable 350, and executable-formed objects 360. There are two types ofexecutable-formed objects: catalog object and cart object.

[0120] A catalog executable-formed object 360 has three methods: a listmethod (non-synchronized, read) that generates a list of commoditiesavailable in the shopping system; a start method (non-synchronized,read) that activates a cart object to be handled on the WWW browser; andan end method (non-synchronized, read) that deactivates a cart object.

[0121] Only one catalog object is activated in the shopping system. Whenthe user selects a link in the HTML-format file hypertext shown on theWWW browser window, the linked method of the only catalog object isexecuted. The list method obtains commodity information such ascommodity list from the database, marks up the information into anHTML-format file, and returns this file to the WWW browser as the resultof method execution. The start method activates the user program forobject management 330 for cart objects via the network and activates acart object to be assigned to the WWW browser. Then, the start methodembeds the object code identifier and object data identifier of theactivated cart object into an HTML-format file and returns this file tothe WWW browser as the result of method execution. The end methodreceives the object code identifier and object data identifier of a cartobject assigned to the WWW browser as the arguments thereto, activatesthe user program for object management 330 for cart objects, anddeactivates the cart object.

[0122] A cart executable-formed object 260 has two methods: a put method(synchronized, write) that adds an commodity identifier that is suppliedas an argument thereto to a member of the cart object; and a buy method(synchronized, write) that determines buying a commodity or commoditiesidentified by the commodity identifier(s) held in the cart object. Thecart object also has the member to contain strings of commodityidentifiers. When the cart object is activated, this member contains nocommodity identifier.

[0123] When the start method for s cart object is executed, the cartobject is activated and assigned to the WWW browser. When the end methodof the catalog object is executed, the cart object assigned to the WWWbrowser is deactivated. When the user selects a link in the HTML-formatfile hypertext shown on the WWW browser window, the linked method of thecart object assigned to the WWW browser is executed. The put methodreceives a commodity identifier as the argument thereto and saves itinto the member for holding the commodity identifier. The buy methodadds the strings of the commodity identifiers saved in the member to thedatabase and saves the commodity information determined to be bought.

[0124] There are two types of user programs for object management 330:the program for catalog objects and the program for cart objects.

[0125] The user program for object management 330 for catalog objects isexecuted when starting the shopping system itself and activates onecatalog object. This program is also executed when terminating theshopping system and deactivates the catalog object.

[0126] The user program for object management 330 for cart objects isactivated and executed via the network 10, following the execution ofthe start method of the catalog object on the server-run computer 200-aor 200-b triggered by a request message from the WWW browser. Thisprogram activates a cart object to be handled on the WWW browser inaddition to the active catalog object. This program is also activatedand executed via the network, following the execution of the end methodof the catalog object on the server-run computer 200-a or 200-btriggered by a request message from the WWW browser 700. This methoddeactivates the cart object to be handled on the WWW browser.

[0127] When the shopping system starts up, the object code of thecatalog object and the object code of the cart object are registeredinto the object code table 350. At the same time, one object data set ofthe catalog object and as many object data sets of the catalog object asthe number of WWW browsers that are running for shopping, each data setcorresponding to each WWW browser run for shopping, are registered intothe object data table 340.

[0128] In the present application example, a computer for commoditydatabase, which is not shown, is assumed connected to the network 100.On this computer for commodity database, an area is allocated in whichcommodity information such as lists of commodities available by usingthe shopping system has been stored and another area is allocated intowhich information for a commodity bought by the user is stored when theuser determines to buy the commodity. In the architecture of theshopping system, the computer for commodity database is to be used bythe catalog object and the cart object. Specifically, the list method ofthe catalog object retrieves commodity information such as a list ofcommodities from the database on the computer for commodity database.The buy method of the cart object adds the information for a commoditydetermined to be bought to the database on the computer for commoditydatabase.

[0129] A request message is sent from a WWW browser to a WWW server byselecting one of the links in the HTML-format file hypertexts shown onthe WWW browser window. In response to the request message, the programcode of the requested method of the specified object is executed. Theresult of the method execution is marked up into an HTML-format filethat is sent back to the WWW browser as the response. This processcorresponds to the process from remote object invocation that isinitiated by the user program 110, method execution, that is, theprogram code of the requested method of the specified object isexecuted, until the result of the method execution is returned to theuser program 110.

[0130] Next, the relation between the links in HTML-format filehypertexts and the methods of the catalog or cart object will beexplained below. Assume that an HTML-format file hypertext including thelinks to the methods of the catalog or cart object is shown on thewindow of the WWW browser active on the client-run computer 100. Whenthe user selects one of the links, the linked method is executed on theserver-run computer 200-a or 200-b. The program code of the selectedmethod is executed and the result of execution is marked up into anHTML-format file that is sent back as the response. The WWW browserdisplays the text of the HTML-format file received as the response. Inthe present application example, how transition from one HTML-formatfile hypertext to another HTML-format file hypertext occurs by selectinga link and how the links are organized in each HTML-format filehypertext are not definitely specified herein. A simple example casewill be explained below. A first HTML-format file hypertext is assumedto include a link to the list method. When the user selects the link tothe list method, a commodity list is shown and the transition to asecond HTML-format file hypertext that includes a link to the startmethod occurs. By selecting the link to the start method in the secondHTML-format file hypertext, the transition occurs to a third HTML-formatfile hypertext that includes a put method link or form that allows theuser to specify a commodity identifier as well as a link to the buymethod. By selecting the put method link, the transition to another itemoccurs within the same third HTML-format file hypertext, so that theuser can repeatedly select the put method link until the buy method linkhas been selected in the third HTML-format file hypertext. By selectingthe buy method link, the transition occurs to a fourth HTML-format filehypertext including a message that notifies the user that purchase hasbeen fixed as well as a link to the end method. By selecting the endmethod link in the fourth HTML-format file hypertext, the transition tothe first HTML-format file hypertext occurs.

[0131] Then, how the shopping system starts and terminates in thepresent application example will be explained below. To start theshopping system the user program for object management 330 for catalogobjects is executed on the managing computer 300. The user program forobject management 330 for catalog objects requests the object managerunit 320 to activate one catalog object. The object manager unit 320retrieves a catalog object from the database of executable-form objects360 and registers its object code and object data into the object codetable 350 and the object data table 340 respectively, thus activatingthe catalog object. To terminate the shopping system, the user programfor object management 330 for catalog objects is executed as is forstarting the shopping system and issues a request to deactivate thecatalog object.

[0132] Next, browsing a commodity list on the WWW browser window, thatis, executing the list method of the catalog object by request from theWWW browser will be explained below. It is assumed that an HTML-formatfile hypertext including a link in which the object code identifier andobject data identifier of the catalog object and the list method nameare embedded is shown on the WWW browser window. When the user selectsthe above link, a request message containing the above information suchas the object code identifier is sent from the WWW browser to the routerwith a load balancing feature, not shown. Upon the reception of thisrequest message, the router with a load balancing feature sends therequest message to the server-run computer 200-a or 200-b, according tothe round robin scheduling or load condition. Assume that the routerselects the server-run computer 200-a as the destination.

[0133] The WWW server on the server-run computer 200-a receives therequest message and transfers it to the object invocation unit 220-a.The object invocation unit 220-a obtains the catalog object from theobject access unit 310 on the managing computer 300 and executes thelist method. The list method retrieves commodity information such as alist of commodities from the commodity database and marks up theinformation into an HTML-format file that is sent back to the WWWbrowser on the client-run computer 100 as the response. At this time,the access unit 310 on the managing computer 300 is not requested tooverwrite the object data after method execution, because the listmethod is a method of non-synchronized and read attributes. If aplurality of WWW browsers simultaneously issue the requests to executethe list method, the list method execution takes place concurrently on aplurality of server-run computers without being serialized, because thelist method is a method of non-synchronized and read attributes.

[0134] Next, starting and terminating shopping on the WWW browserwindow, that is, executing the start method and the end method of thecatalog object by request from the WWW browser will be explained below.As is the case for browsing a commodity list on the WWW browser window,the start method of the catalog object is executed by request from theWWW browser. The start method activates the user program for objectmanagement 330 for cart objects, accessing the managing computer 300 viathe network 10. The user program for object management 330 for cartobjects requests the object manger unit 320 to additionally activate acart object. The object manager unit 320 retrieves a cart object fromthe database of executable-formed objects 360 and additionally activatesthe cart object. The start method obtains the object data identifier ofthe activated cart object via the network 10 and generates anHTML-format file containing a hypertext in which the cart object codeidentifier, the object data identifier of the activated cart object, andthe put and buy method names are embedded. The HTML format file is sentback to the WWW browser as the response. The activated cart object is tobe handled by the WWW browser. To terminate shopping, the end method isexecuted in the same manner as for the start method and the end methoddeactivates the cart object to be handled by the WWW browser.

[0135] Next, shopping on the WWW browser window, that is, executing theput method and the buy method of the cart object by request from the WWWbrowser will be explained below. It is assumed that an HTML-format filehyper text including links of commodities that allow the user to input acommodity identifier thereto (Links allowing the user to input datathereto are, in fact, forms in HTML-format file hypertexts, but therepresentation of links instead of forms is used herein) as well as thebuy link is shown on the WWW browser window. In these links ofcommodities, the cart object code identifier, the object data identifierof the cart object assigned to the WWW browser, and the put method nameare embedded, and a commodity identifier input thereto by the user isused as the argument to the method. The action that the user inputs ancommodity identifier to a commodity link and selects the link means thatthe user selects the commodity input thereto. In the buy link, the cartobject code identifier, the object data identifier of the cart objectassigned to the WWW browser, and the buy method name are embedded. Theaction that the user selects this link means that the user determines tobuy the commodity or commodities that the user has selected.

[0136] Wen the user inputs an commodity identifier to a commodity linkand selects the link on the WWW browser window, a request messagecontaining the object data identifier and the commodity identifier asthe argument to the method is generated. In the same manner as forbrowsing a commodity list on the WWW browser window, the request messageis transferred to the object invocation unit 220-a on the server-runcomputer 200-a. The object invocation unit 220-a obtains the cart objectfrom the object access unit 310 on the managing computer 300 andexecutes the put method. The put method adds the commodity identifier asthe argument passed thereto to the appropriate member of the cartobject, and consequently the object data is altered. Then, the objectinvocation unit 220-a requests the object access unit 310 on themanaging computer 300 to overwrite the object data of the cart object,because the put method is a method of synchronized and write attributes.The object data of the cart object in the object data table 340 isoverwritten with the object data to which the commodity identifier hasbeen added. Thereafter, the methods of the object can read the addedcommodity identifier.

[0137] When the user inputs another commodity identifier to anothercommodity link and selects the link on the WWW browser window and theput method of the cart object is executed again, the specified commodityidentifier is added to the member in position just after the precedingcommodity identifier.

[0138] According to how the router with a load balancing feature selectsa server-run computer, the put method may be executed on the server-runcomputer 200-a at the first time of remote object invocation and on theserver-run computer 200-b at the second time of remote objectinvocation. If the user splits the WWW browser window into sub-windows,inputs different commodity identifiers on the sub-windows, andsimultaneously selects the links of the commodities, the put methodexecution is serialized, because the put method is a method ofsynchronized and write attributes.

[0139] When the user selects the buy link on the WWW browser window, thesame processing as the buy method execution is performed. The buy methodsaves the commodity identifier or identifiers added to the member of thecart object into the commodity database.

[0140] Then, system expansion to cope with rapid traffic increase in thepresent application example will be explained below. If rapid increaseof the access to the shopping system occurs beyond the processingcapacity of the server-run computers, a new computer must be added tothe cluster of the server-run computers. In this case, system expansionis possible by connecting a new computer equipped with a WWW server andthe object invocation unit to the network and altering the systemoperation such that the router with a load balancing feature sendsrequest messages to the new computer as well.

[0141] Furthermore, system service alteration to meet a service changerequest in the present application example will be explained below. If,for example, the commodity list display form is altered, thespecification of the list method of the catalog object must be altered.Such system service alteration is possible by deactivating the catalogobject on the managing computer 300, replacing the object by a newcatalog object as the executable-formed object 360 made to the alteredspecification, and activating the new catalog object.

[0142] As explained above, the distributed object system in the presentembodiments was designed to work as follows. With an object being notactive on the sever-run computers in advance, in response to a remoteobject invocation from a client-run computer, the requested method isexecuted on one of the server-run computers with the object code andobject data being obtained from the managing computer, and moreover themanaging computer is requested to overwrite the object data. Therefore,when a server-run computer is added to the cluster of the server-runcomputers due to insufficient capacity, it is not necessary to activateobjects in advance on the new server-run machine and easy systemexpansion is possible. According to the conventional method, when a newcomputer is added to the server cluster system, it is necessary toinstall objects on the new computer and activate the objects. Bycontrast, it is not necessary for the present embodiments to install andactivate objects on the new computer, because objects are installed andactivated only the managing server, and therefore system expansion iseasy. (In other words, in response to a service request issued from aclient, the managing computer retrieves the object (program) requiredfor the service request and sends it to one of the server-run computers.Thus, the server-run computers need not to be furnished with objects inadvance.)

[0143] Furthermore, the distributed object system in the presentembodiments was designed such that objets are activated or deactivatedonly on the managing server without being done on a plurality ofserver-run computers. Thus, easy system alternation is possible; when anobject is renewed, it is deactivated on the managing computer, replacedby a new object, and the new object is activated there. (By request froma client, the managing computer issues the request to activate ordeactivate the object that runs on one of the server-run computers.Thus, the server-run computers need not perform object management.)

[0144] According to the conventional method, when renewing objects thatare active on a plurality of server-run computers to alter a serviceprovided by the server system, it is necessary to deactivate each objecton each server-run computer, and replace it by a new object, andactivate the new object.

[0145] By contrast, it is not necessary for the present embodiments toperform such object exchange on each server-run computer, becauseobjects are installed and activated only on the managing server. Systemalteration is easy; an object to change is deactivated only on themanaging computer, it is replaced by a new object, and the new object isactivated there.

[0146] The present invention produces the effect of easy systemexpansion; when a new computer is added to the cluster of the server-runcomputers, objects need not be activated on the new computer in advance.

[0147] The present invention also produces the effect of easy systemalteration; when a service provided by the server system is altered, anobject to change is deactivated only on the managing computer, it isreplaced by a new object, and the new object is activated there.

[0148] While a preferred embodiment has been described, variationsthereto will occur to those skilled in the art within the scope of thepresent inventive concepts which are delineated by the following claims.

1. An object management method applicable to a distributed objectsystem, the system comprising at least one client-run computer, at leastone server-run computer, and at least one managing computer, the methodcomprising: providing the at least one server-run computer with a loadbalancing feature, obtaining object code and object data from the atleast one managing computer in response to a remote object invocationfrom the at least one client-run computer, executing a requested methodof the object on the at least one server-run computer, and performingobject data overwrite on the at least one managing computer.
 2. Themethod of claim 1 , comprising at least one of activating objects anddeactivating objects only on the at least one managing computer.
 3. Themethod of claim 1 , comprising performing serialized object invocationand method execution on the at least one server-run computer when aplurality of remote object invocations of a same object to execute asynchronized method of the object are issued from the at least oneclient-run computer.
 4. The method of claim 1 , comprising performingconcurrent object invocation and method execution on the at least oneserver-run computer when a plurality of remote object invocations of asame object to execute a non-synchronized method of the object areissued from the at least one client-run computer.
 5. The method of claim1 , comprising requesting the at least one managing computer tooverwrite the object data and change the object data use flag when awrite method is executed on the at least one server-run computer.
 6. Themethod of claim 1 , comprising performing both object data overwrite andobject data use flag change on the at least one server-run computer whena read-only and non-synchronized method is executed on the at least oneserver-run computer.
 7. The method of claim 1 , comprising requestingthe at least one managing computer to simply update the object data useflag when a read-only and synchronized method is executed on the atleast one server-run computer.
 8. The method of claim 1 , comprisingproviding an object database containing catalog object and data and cartobject and data.
 9. A server-run computer, comprising: an objectinvocation unit, and a load balancing unit for selecting the server-runcomputer to perform a method execution task according to a loadcondition and for sending a request message to the object invocationunit of the selected server-run computer, wherein the object invocationunit receives the request message from the load balancing unit, sends arequest for object code and object data to a managing computer, receivesobject code and object data from the managing computer, executes therequested method, and sends object data fixed after method execution anda request for object data overwrite to the managing computer.
 10. Amanaging computer, comprising: an object access unit for receiving arequest to obtain object code and object data from a server-runcomputer, obtaining object code from an object code table and obtainingobject data from an object data table, sending the obtained object codeand the obtained object data to the server-run computer, receivingobject data fixed after method execution and a request for object dataoverwrite, and writing object data fixed after method execution overcorresponding object data in the object data table, and an objectmanager unit for receiving a command to activate an object from anobject management user program, retrieving the object from a database ofexecutable-formed objects, registering object code into an object codetable wherein object codes are stored, and registering object data intoan object data table wherein object data are stored, wherein the objectmanagement user program provides at least one object activation commandand at least one object deactivation command to the object manager unit,and wherein the database of executable-formed objects comprising theobjects are represented as executable programs.
 11. A program forimplementing an object management method applicable to a distributedobject system, the distributed object system comprising at least oneclient-run computer, at least one server-run computer, and at least onemanaging computer, the program comprising a program for: providing theat least one server-run computer with a load balancing feature,obtaining object code and object data from the at least one managingcomputer in response to a remote object invocation from the at least oneclient-run computer, executing a requested method of the object on theat least one server-run computer, and performing object data overwriteon the at least one managing computer.